RespeQt 5.4.1

hi, sehr schön - aber - die Windows-Verion benötigt die libzlib1.dll - ist in der Zip-Datei nicht vorhanden und im Installer auch nicht. Grüße, Ingo

habe da noch einen:

BöserWatz schrieb: habe da noch einen: Screenshot 2026-01-13 190332.png

Wurde vermutlich mal mit SIO2PC erstellt und ist ein "zu kurzes" 64k Image, das keiner realen/vollen Diskette entspricht (Single/90k wären als ATR 92.176 Byte oder so).

Kann man mit versch. Tools auf dem PC reparieren bzw. auf die richtige Länge bringen (z.B. ATRFIX.exe).

Das ist derselbe Schrott, wie die k-Files, die aber variable Längen haben.

Nichtsdestotrotz könnte RespeQt solche Krüppelfiles - wenn sie einen ATR-Header haben - einfach als SD/90KB nur-lesend mounten.

CharlieChaplin schrieb: Wurde vermutlich mal mit SIO2PC erstellt und ist ein "zu kurzes" 64k Image, das keiner realen/vollen Diskette entspricht (Single/90k wären als ATR 92.176 Byte oder so).

die Version 5.4.1RC2 konnte das noch

JoSch schrieb: RespeQt ist da jetzt konsequenter, um fehlschreiben zu vermeiden.

Ich würde mich mit dem Schreiben auf diese Schrottimages nicht aufhalten und sie einfach nur-lesend öfnen - sinnvollerweise zusammen mit einem Hinweis auf diesen Umstand.

JoSch schrieb: Ja, ich habe die Behandlung der ATR-Images wegen den ganzen Problem mit gepadetten und nichtgepadetten Dateien angepasst. RespeQt ist da jetzt konsequenter, um fehlschreiben zu vermeiden. @BöserWatz: Schickst Du mir bitte die Datei.

Nach dem ATR-FIX kann das Image gelesen werden. Also, ist das kein Fehler.

JoSch schrieb: Die fehlende DLL-Datei sollte jetzt im Release enthalten sein.

Passt

Ich habe mir die Version noch mal ausführlicher in Bezug auf Kopierschutz angesehen. Der Vorgang für Happy Modus läuft so:

Aufbau - RespeQt 5.4.1 auf Windows 10 oder 11 (Parameter Schnittstelle siehe Bild - es läuft auch ohne "Nutze non-standard Geschwindigkeiten") - Eine echte Happy 7.1 als D2 - SIO2PC an Laufwerk und Atari Rechner und am Windows 10 Rechner am USB-Port

Ablauf - echtes Laufwerk aus und anschalten = Happy Modus - D1 in RespeQt mit "Happy Warp Speed Software v7.1" mounten (wird von RespeQt später aus Performancegründen gepatched) - Happy Modus für D1 einschalten - Atari einschalten (Happy Software lädt das Menü und zeigt Happy Drives D1 und D2) - am Atari Menüpunkt 4 auswählen (Happy Backup) - D1 in RespeQt mit der zu kopierenden ATX-Disk mounten (HAPPY Modus bleibt an) - Im Happy Backup Programm auf dem Atari N drücken (wir nutzen hier keine PBD) und die Laufwerke werden vorbereitet - Das Happy Backup zeigt im Atari das Hauptmenü und mit S können spezielle Parameter gesetzt werden ("Skew align mode" wurde früher empfohlen, ich konnte auch ohne Kopien erzeugen) - Im Atari C drücken für letzten Stepp vor dem Kopieren - dann Return am Atari drücken und der Kopiervorgang startet von dem virtuellen in das reelle Laufwerk

Der Ablauf muss für jedes neue Programm mit dem Boot von Happy Warp Speed Software 7.1 starten.

Bisher für folgende Programm geprüft (Testumgebung 800XL und normale 1050): - Pooyan - Ghostbusters (mit Speech) - Boulder Dash - Dig Dug - Ballblazer Activision Rel. (liess sich nicht kopieren im Happy Mode - auch nicht mit Parameter A) - Boulder Dash II (meldet es muss eine PBD Datei genutzt werden und hört bei Track 37 auf) - Archon (ging eigentlich - muss noch mal mit Copyparameter geprüft werden)

Der Vorgang für Chip Modus läuft so:

Aufbau - RespeQt 5.4.1 auf Windows 10 oder 11 (Parameter Schnittstelle siehe Bild) - Eine echte 1050 mit Copy Card 7.0 als D2 (mit der Happy 7.1 hatte ich hier Probleme) - SIO2PC an Laufwerk und Atari Rechner und am Windows 10 Rechner am USB-Port

Ablauf: - in RespeQt Laufwerk D1 mit CHIP Mode "Happy 1050 to Chip Converter (19xx)(Marquis).atr" mounten - Laufwerk D2 ist eine echte 1050 mit Copy Card 7.0 - Booten -> die 1050 wird auf CHIP mode gewechselt - nun im RespeQt Laufwerk D1 "Archiver, The v1.2 (198x)(Spartan Software).atr" mounten - die Version läßt D2 auswählen - Booten -> Archiver lädt - nun im RespeQt Laufwerk D1 "Spiel.atx" mounten - kopieren - fertig

Bisher erfolgreich kopiert (Test auf 800XL mit Standard 1050): - Pooyan - Dig Dug - Ghostbusters (Speech Vers.) - Ballblazer (Activision Rel.) kann nicht gelesen werden ("Archiver, The v1.2 (198x)(Spartan Software).atr", "Archiver, The v1.1 (198x)(Spartan Software).atr" oder "Archiver and Editor v1.2, The (198x)(Spartan Software of MN)(US).atr" - mir war so, dass ich das schon mal hinbekommen habe - naja)

Ich habe mir den Bitwriter Replica 1050 bestellt - ggf. geht damit auch Ballblazer und Boulder Dash II - dann bericht ich noch mal.

Schön eine neue Version. Werde ich später hoffentlich testen, nachdem das Magazin in der Post ist.

BöserWatz schrieb: - Ballblazer Activision Rel. (liess sich nicht kopieren im Happy Mode - auch nicht mit Parameter A) - Boulder Dash II (meldet es muss eine PBD Datei genutzt werden und hört bei Track 37 auf) - Archon (ging eigentlich - muss noch mal mit Copyparameter geprüft werden)

Ballblazer und die anderen drei Klassiker, die Europa Versionen von Activison, lassen sich mit der Speedy und dem Programm MS-Copy Sicherheits-Kopieren. Modus 2 und J.

Boulder Dash 2 und andere von Databyte gehen nur mit der Kombi Super-Archiver 3.03+Bitwriter. Track 0-36 Super-Archiver 3.03, Track 37-39 Bitwriter. Oder alles mit dem Bitwriter, dauert aber. Der Sektor Skew muss aktiviert sein! Sonst läuft es nicht. Der Databyte Schutz ist eh Grütze, da kann DjayBee mehr erzählen.

Archon kann mit Happy (Version 1). Die neuere (Version 2) nur mit Bitwriter (Track 2 reicht, enthält 37 Sektoren).

Habe von meinen Originalen alles als BackUp 😎

Na dann werde ich später 🙄 auch mal mit RespeQt rumspielen 😁

DjayBee schrieb: Das ist derselbe Schrott, wie die k-Files, die aber variable Längen haben.

Nichtsdestotrotz könnte RespeQt solche Krüppelfiles - wenn sie einen ATR-Header haben - einfach als SD/90KB nur-lesend mounten.

Ist daran gedacht, das evtl. noch einzubringen?

Ich stolpere immer wieder mal über solche Images, habe aber kein brauchbares Tool für Linux, um das zu fixen.

GoodByteXL schrieb:

DjayBee schrieb: Das ist derselbe Schrott, wie die k-Files, die aber variable Längen haben.

Nichtsdestotrotz könnte RespeQt solche Krüppelfiles - wenn sie einen ATR-Header haben - einfach als SD/90KB nur-lesend mounten.

Ist daran gedacht, das evtl. noch einzubringen?

Ich stolpere immer wieder mal über solche Images, habe aber kein brauchbares Tool für Linux, um das zu fixen.

Ich weiß nicht, ob JoSch das noch macht.

Wenn du aber unter Linux arbeitest, sollte folgendes ein ATR mit korrekter Länge erzeugen:

dd if=schrott.atr of=gutes.atr bs=90K conv=sync

Wäre schön, wenn repariert würde, daß die großen ATRs (128 MB ?) für das Programmieren von The!Cart wieder funktionieren ...

Korektur für oben, weil ich den ATR-Header übersehen hatte und das Ergebnis deshalb 16 Bytes zu klein ist:

dd if=schrott.atr of=gutes.atr bs=92176 conv=sync

Für XFDs, also ohne Header passt der erste Ansatz mit den 90K.

DjayBee schrieb: Korektur für oben, weil ich den ATR-Header übersehen hatte und das Ergebnis deshalb 16 Bytes zu klein ist:

dd if=schrott.atr of=gutes.atr bs=92176 conv=sync

Naja, ein Fix halt mit dieser Ausgabe:

Image size of '/home/itsme/Zybexfixed2.atr' is reported as 50176 bytes in the header but it's actually 92160.
[Disk 3] 'Zybexfixed2.atr' als 'SD Diskette (90k)' gemountet.

Aber das ATR startet. Danke für den Tipp.

GoodByteXL schrieb: Naja, ein Fix halt mit dieser Ausgabe:

Image size of '/home/itsme/Zybexfixed2.atr' is reported as 50176 bytes in the header but it's actually 92160. [Disk 3] 'Zybexfixed2.atr' als 'SD Diskette (90k)' gemountet.

Ah, die Imagegröße im Header ist korrekt für die falsche Dateigröße. Dann probier folgendes:

dd if=schrott.atr of=gutes.atr bs=92176 conv=sync

# Überschreibt die ersten fünf Byte im Header mit den korrekten Werten für SD
echo "00000000: 96 02 80 16 80" | xxd -r - gutes.atr

Danke, funzt. Für gelegentliche Fixes reicht es mir aus.

.

JoSch schrieb: Das ist doch länger gefixt. Oder ist der Fehler wieder aufgetaucht?

Als ich vor ein paar Wochen die Tests für The!Cart gemacht hatte mußte ich auf AspeQt ausweichen ...

Erhard schrieb: .

JoSch schrieb: Das ist doch länger gefixt. Oder ist der Fehler wieder aufgetaucht?

Als ich vor ein paar Wochen die Tests für The!Cart gemacht hatte mußte ich auf AspeQt ausweichen ...

Oder man nimmt V. 5.4.0, wenn das Fixen zu lästig ist.

32MB Images (512 bytes pro Sektor) sind in 5.4.1 übrigens auch kaputt:

Cannot open '/tmp/qd.atr': Invalid image size (33553920).

so long,

Hias

JoSch schrieb:

HiassofT schrieb: 32MB Images (512 bytes pro Sektor) sind in 5.4.1 übrigens auch kaputt:

Cannot open '/tmp/qd.atr': Invalid image size (33553920).

so long,

Hias

Wie hast Du das erzeugt?

Mit RespeQt:

so long,

Hias

Für das 128 MB ATR für The!Cart braucht man mindestens 2048 Byte Sektoren (65536 * 2048 = 128M). Welche Sektorgröße da jetzt tatsächlich vom The!Cart Studio erzeugt / verwendet wird müßte man nochmal nachschauen. Die SIO kann halt nur 65535 Sektoren adressieren. Das ergäbe aber bei 2K Sektorgröße 128MB minus 2K.

@Peter: was sagst Du dazu?

Erhard schrieb: Für das 128 MB ATR für The!Cart braucht man mindestens 2048 Byte Sektoren (65536 * 2048 = 128M). Welche Sektorgröße da jetzt tatsächlich vom The!Cart Studio erzeugt / verwendet wird müßte man nochmal nachschauen. Die SIO kann halt nur 65535 Sektoren adressieren. Das ergäbe aber bei 2K Sektorgröße 128MB minus 2K.

@Peter: was sagst Du dazu?

Die The!Cart images haben 15361 8k grosse Sektoren

Zusätzlich zu den 128MB Cart Daten (15360 8k Sektoren) steckt da noch ein weiteer Sektor mit den Metadaten drin.

so long,

Hias

HiassofT schrieb: Die The!Cart images haben 15361 8k grosse Sektoren

Zusätzlich zu den 128MB Cart Daten (15360 8k Sektoren) steckt da noch ein weiteer Sektor mit den Metadaten drin.

Sorry, da hab ich Blödsinn geschrieben und es ist leider schon zu spät zum Editieren.

Es sind natürlich 16385 8k Sektoren (16384 für die Daten und ein Metadaten Sektor) - keine Ahnung wie ich da auf 15360 kam.

so long,

Hias

.

HiassofT schrieb: Es sind natürlich 16385 8k Sektoren (16384 für die Daten

paßt auch direkt besser zu 128 MB 🙂

Zur Info: der ATR-Header eines 128MB ATR für The!Cart sieht wie folgt aus:

96 02 00 02 00 20 80 00 00 00 00 00 00 00 00 00
----- ----- ----- ----- ----------- -- -- -- --
  |     |     |     |        |       |  |  |  |
  |     |     |     |        |       |  |  |  ----- Bit 0 = schreibgeschützt, Bit 1 (APE) = versiegelt
  |     |     |     |        |       |  |  -------- unused
  |     |     |     |        |       |  ----------- unused
  |     |     |     |        |       -------------- unused
  |     |     |     |        ---------------------- 32-Bit CRC (Nur mit APE)
  |     |     |     ------------------------------- Imagegröße (*1) /16 hi-word
  |     |     ------------------------------------- Sektorgröße (128 / 256 Bytes)
  |     ------------------------------------------- Imagegröße (*1) /16 lo-word
  ------------------------------------------------- "Nickatari" Signatur

  *1) Imagegröße
---------------
  Anzahl der Bootsektoren (3) * 128 Byte
+ Anzahl der restl. Sektoren  * 128 o. 256 Byte

Ich bin jetzt irgendwie nicht sicher, ob das mit der Imagegröße paßt?

16385 * 8192 = 134.225.920 134.225.920 + 16 = 134.225.936

Die 134.225.936 entsprechen exakt der Größe der Datei, die The!Cart Studio erzeugt.

Wenn ich nun den Wert für Imagegröße aus dem ATR-Header nehme:

$80000002 = 2.147.483.650 2.147.483.650 * 16 = 34.359.738.400

paßt das irgendwie nicht, oder?

Anders herum gerechnet:

134.225.920 / 16 = 8.389.120 = $800200

Kann es sein, daß bei Imagegröße Hi-Word The!Cart Studio Low-Byte und High-Byte vertauscht?

Erhard schrieb: Zur Info: der ATR-Header eines 128MB ATR für The!Cart sieht wie folgt aus:

``` 96 02 00 02 00 20 80 00 00 00 00 00 00 00 00 00

---

| | | | | | | | | | | | | | | | | ----- Bit 0 = schreibgeschützt, Bit 1 (APE) = versiegelt | | | | | | | -------- unused | | | | | | ----------- unused | | | | | -------------- unused | | | | ---------------------- 32-Bit CRC (Nur mit APE) | | | ------------------------------- Imagegröße (1) /16 hi-word | | ------------------------------------- Sektorgröße (128 / 256 Bytes) | ------------------------------------------- Imagegröße (1) /16 lo-word ------------------------------------------------- "Nickatari" Signatur

*1) Imagegröße

Anzahl der Bootsektoren (3) * 128 Byte + Anzahl der restl. Sektoren * 128 o. 256 Byte

```

Ich bin jetzt irgendwie nicht sicher, ob das mit der Imagegröße paßt?

16385 * 8192 = 134.225.920 134.225.920 + 16 = 134.225.936

Die 134.225.936 entsprechen exakt der Größe der Datei, die The!Cart Studio erzeugt.

Wenn ich nun den Wert für Imagegröße aus dem ATR-Header nehme:

$80000002 = 2.147.483.650 2.147.483.650 * 16 = 34.359.738.400

paßt das irgendwie nicht, oder?

Anders herum gerechnet:

134.225.920 / 16 = 8.389.120 = $800200

Kann es sein, daß bei Imagegröße Hi-Word The!Cart Studio Low-Byte und High-Byte vertauscht?

Alle Words werden in der Reihenfolge Low-Byte, Hi-Byte gespeichert - Du hattest die da verdreht.

Image Size 00 02 80 00 ergibt also $00800200, Sector Size 00 20 ist $2000

Das passt also alles: $800200 mal 16 = $8002000 = 134225920

so long,

Hias

.

HiassofT schrieb: Du hattest die da verdreht.

Danke für die Korrektur. Ich passe meine Doku entsprechend an.

(Weil da "hi-word" und "lo-word" steht ging ich nicht vom A8-gebräuchlichen Little-Endian Format aus).

Speichere das 32MB Image als ATR, schliesse RespeQt und versuche es zu laden - dann kommt der Fehler.

so long,

Hias

Der Fehler kommt auch beim Versuch, früher mit älteren Versionen von RespeQt generierte 32MB-ATRs zu mounten.

JoSch schrieb: Naja, es gibt eine Sonderbehandlung von Sektoren mit 256 Byte, aber nicht für 512 Bytes. Daher wird das Image dann mit 128 Byte Sektoren berechnet und das geht halt schief. Ich versuche das irgendwie zu lösen.

Mach es so wie es die letzten ca 15 Jahre in AspeQt und RespeQt war:

Nur die 256-byte Images brauchen die "Spezialbehandlung" mit den 3 128-byte grossen Bootsektoren, bei allen anderen Sektorgrössen sind alle Sektoren gleich gross.

Das ist einfach und klappt mit 128, 512, 8k und auch allen anderen Grössen.

so long,

Hias

JoSch schrieb: Bitte testen.

Kann mit SDX nun wieder alte 32 MB große Images nutzen und neue erzeugen. Fehler traten bisher nicht auf.

Danke für den Fix.

Alter Mann (ich) findet bei github, sourceforge und Co. ja nix...

Da steht bei RespeQT 5.4.1 zwar "latest" nebendran, aber unten drunter steht "josch1710 released this Jan12". Sind da die letzten Updates vom Mai drin enthalten ? Oder muss ich da doch woanders gucken ? (Wenn es seit Januar Updates gegeben hat, warum hat sich die Versionsnummer dann nicht geändert?)

Wie gesagt, alter Mann...

CharlieChaplin schrieb: Alter Mann (ich) findet bei github, sourceforge und Co. ja nix...

Noch älterer Mann hatte es gleich gefunden ... 😁

Ich bin auch zu blöd und finde nur eine 5.3:

https://github.com/RespeQt/RespeQt/releases

Erhard schrieb: Ich bin auch zu blöd und finde nur eine 5.3:

https://github.com/RespeQt/RespeQt/releases

Du suchst im falschen Repo.

Korrekt ist https://github.com/josch1710/RespeQt/releases/tag/r5.4.1 - siehe erster Post hier im Thread.

Ich habe das ZIP-Archiv für Windows heruntergeladen (und entpackt).

1) Fehlermeldung: ZLIB1.DLL fehlt

Nach Hinzufügen einer ZLIB1.DLL (gibt es an 26 Stellen auf dem PC) in das Verzeichnis von RespeQt

2) Fehlermeldung:

Erhard schrieb: Ich habe das ZIP-Archiv für Windows heruntergeladen (und entpackt).

1) Fehlermeldung: ZLIB1.DLL fehlt

Nach Hinzufügen einer ZLIB1.DLL (gibt es an 26 Stellen auf dem PC) in das Verzeichnis von RespeQt

2) Fehlermeldung:

ERROR.png

Vollkommen unfundierter Kommentar: Stammt das Windows schon aus diesem Millenium?

duck-und-renn